Shopify Customer Churn Prediction
Predict which Shopify customers are likely to churn based on their order history and behavior.
Dataset Source:
Kaggle - Shopify Sales Dataset for ML & EDA
Problem Type: Binary Classification Target Variable: churned — 1 = customer
has churned, 0 = active customer Use Case: Identify at-risk customers to enable
proactive retention campaigns
Churn Definition: A customer is considered churned if they have been a customer for 180+ days AND have not placed an order in the last 90 days. This avoids mislabeling new customers who simply haven't had time to reorder.
Package Imports
Instantiate Xplainable Cloud
Initialise the xplainable cloud using an API key from: https://platform.xplainable.io/
This allows you to save and collaborate on models, create deployments, create shareable reports.
Load Shopify Order Data
This dataset contains 60,000 individual order records from a Shopify store spanning January 2023 to June 2025. We'll aggregate these to the customer level and engineer features for churn prediction.
Feature Engineering
Aggregate order-level data to customer-level features. These map to real Shopify API fields:
- Direct fields:
customer_id,customer_country,orders_count,total_spent - Derived from orders: recency, frequency, monetary value, discount behavior, return rate
- Dominant category: most frequently purchased
product_categoryper customer
Define Churn Label
A customer is churned if:
- They have been a customer for 180+ days (sufficient tenure to establish a purchase pattern)
- They have not placed an order in the last 90 days
Customers with less than 180 days tenure are excluded — they haven't been around long enough to reliably label.
1. Data Preprocessing
The aggregation step above (orders → customers) is business logic that runs before the persistable pipeline. The pipeline below handles transforms on the already-aggregated customer-level data — this is what gets persisted to Xplainable Cloud and runs at inference time.
We use the new PipelineSpec format, which is JSON-serializable and can be versioned,
previewed, and recompiled independently of the fitted state.
Persist Preprocessor to Xplainable Cloud
The PipelineSpec is JSON-serializable, so we can persist it directly. The API stores
both the spec and the fitted pipeline binary, allowing it to be loaded and reused for
inference.
Train/Test Split
2. Model Optimisation
The XParamOptimiser uses Bayesian optimisation to find the best hyperparameters for
the XClassifier, balancing accuracy and computational efficiency.
3. Model Training
4. Model Interpretability and Explainability
The model.explain() method generates an interactive visualisation showing:
- Feature Importances: Which customer attributes are most predictive of churn
- Contributions: How specific feature values push predictions toward churn or retention
5. Model Persisting
Save the trained model to Xplainable Cloud for version tracking, collaboration, and deployment.
6. Model Deployment
Deploy the model to Xplainable's inference endpoint, making it available for real-time churn predictions via API.
7. Testing the Deployment
Activate the deployment, generate an API key, and make a test prediction.
8. AI-Generated Report
9. Contribution-Driven Retention Optimization
The xplainable model doesn't just predict whether a customer will churn — it explains why via per-feature contribution scores. Crucially, several of these features represent controllable business levers that exist in the dataset:
orders_count/unique_products— drive repeat purchases through recommendationstotal_shipping— offer free shipping to increase engagementtotal_spent— use discounts to increase basket sizeunique_categories— cross-category recommendationsavg_discount_pct/has_used_discount— incentivize with targeted offers
The model's partition profiles tell us the measured churn reduction when a customer
moves from one partition to another. For example, if orders_count at 1 order scores
+0.012 (toward churn) and at 3 orders scores -0.048 (toward retention), that's a 6pp
churn reduction — derived from the data, not assumed.
We use these counterfactual partition shifts as the lever effects, then calculate the net expected value of each intervention per customer.
Extract Contributions, CLV, and Counterfactual Lever Effects
For each controllable feature, the lever effect is the difference between a customer's current contribution score and the best achievable partition score. This tells us how much churn probability would drop if we successfully moved that customer to the best partition — measured from the data.
Map Levers to Actions and Costs
Each controllable feature maps to a concrete business action. The lever effect comes from the model (data-driven), the cost is a business input (replace with your actual costs).
Expected Value Optimization
The net EV now uses the model-derived lever effect instead of an assumed prevention rate:
Net EV = lever_effect x CLV - lever_cost
Where lever_effect is the counterfactual churn reduction from the model's partition
profile — the measured difference between the customer's current partition and the best
achievable partition for that feature.
Budget-Constrained Allocation
Rank customers by ROI and allocate a fixed monthly retention budget to the highest-return interventions first.
Diminishing Returns Analysis
Each additional dollar of retention spend yields less marginal return. This helps identify the inflection point where additional budget stops being worthwhile.
What's Data-Driven vs What's Assumed
This optimization separates model outputs from business inputs:
From the model (data-driven):
- Churn probability per customer (base_value + contributions)
- Per-feature contribution scores explaining why each customer is at risk
- Counterfactual lever effects: how much churn probability changes if a feature moves from its current partition to the best partition
- CLV estimates (from actual purchase frequency and AOV)
Business inputs (replace with your actuals):
- Intervention costs ($0.50 for an email, $3 for loyalty enrollment, etc.)
- The assumption that moving a feature to a better partition is achievable via the mapped action
The lever effects are the key differentiator. Instead of assuming "a discount reduces
churn by 12%", the model tells us: "for this customer, their unique_products
contribution is +0.012 (toward churn), and the best partition is -0.086 — so getting
them to buy more products could reduce their churn score by 9.8pp." That's measured from
the data, not invented.